We come to the end of Week Four of the AWS Migration Readiness and Planning. What have we done? Well, we have had more meetings about creating things in AWS. We have a space for documenting how we create things in AWS. And we have a project plan that includes tasks for creating things in AWS. What haven’t we done this week? We haven’t created things in AWS.
At times this project feels like one of those “Establishing the context for laying the groundwork for developing the environment to facilitate our capacity to…” projects. Those projects are often associated with zombie committees.
I am not responsible for disaster recovery at Wharton, but I have served on disaster recovery committees at multiple previous employers. Disaster Recovery (and it’s cousin Business Continuity) are a lot like losing weight: Everyone is in favor of it as long it requires no effort. Having a Disaster Recovery committee is a lot like planning a diet—you can feel like you’re doing something without actually doing something.
In our case, the difference between disaster recovery and cloud migration is simple. A disaster is an unexpected event that could occur at any time, or never. Cloud migration could also occur at any time, or never, except that we need to clear out of the Vance data center by May 1, 2020.
The most vexed problem we confront right now is DNS resolution between our cloud landing zone and our on-premises resources. DNS, for those who don’t know, is a service that translates user-friendly names like http://www.korea-dpr.com to computer-friendly addresses like 87.98.231.40.* The problem is not new; we have been talking about this for over a year. Kevin Min and Antonio Vivas have researched multiple alternatives, all of which are sub-optimal in some way. We talked about it again in three different kickoff meetings with AWS and Enquizit, with no decisions being made and nothing being done.
But now,
…at my back I always hear
Time’s wingèd chariot hurrying near
We need a decision and we need to accept that it won’t be a great DNS solution. We implement it (at last, doing something). And then we talk about what the next thing is that we need to decide.
* For those who do know, I am aware that my description of DNS is highly simplified. I could write a five-thousand word description of DNS and someone would say, “It’s a bit more complicated than that.” You know who you are.